home *** CD-ROM | disk | FTP | other *** search
/ MacTech 1 to 12 / MacTech-vol-1-12.toast / Source / MacTech® Magazine / Volume 12 - 1996 / 12.05 May 96 / 12.05 Tips and Tidbits < prev    next >
Encoding:
Text File  |  1996-04-18  |  6.1 KB  |  178 lines  |  [TEXT/R*ch]
  1.         Invoking Handlers in Scripts, 
  2.         by Name
  3.  
  4. This is completely undocumented, as far as I know, but it may help.  Suppose you
  5. have a script application containing a function:
  6.  
  7. on DoSomething(param1,param2)
  8.     return param1+param2
  9. end DoSomething
  10.  
  11. From C, you just have to send the script application an Apple event like this
  12. one:
  13.  
  14. CLASS: ascr
  15. type: psbr
  16. direct object: "----" "LIST" 
  17.     (the list of AEDescs of parameters to pass to the script function)
  18. additional parameter: "snam" "TEXT" 
  19.     containing the name of the function to call (in our example: “DoSomething”)
  20. et voilà.
  21.  
  22. This method allows to write “clean” scripts, using more memorable handler names,
  23. not using the «CLASStype» syntax.
  24.  
  25. Pierre-Loic Raynaud
  26.  
  27.  
  28.  
  29. [This event is called “Subroutine Call” and is described in more detail in
  30. Chapter 10 of the Apple Event Registry, “The AppleScript Suite”.  On the
  31. Developer Mailing Reference Library CD, the pdf file is named “AppleScript
  32. Suite”, and the information is on pdf page 5 (paper page 7). – jk]
  33.  
  34.  
  35.  
  36.  
  37. ***
  38.  
  39.  
  40.  
  41. Swapping Bytes in a High Level Language, 
  42. the Saga Continues!
  43. You have probably been swamped with everyone’s comments regarding the “Anti-Tip
  44. of the Month” that appeared in MacTech Magazine 11.10 (October 1995).
  45. Greg Poole had the right idea when he submitted his tip about byte-swapping. 
  46. You can tweak code until your fingers fall off, but often the best way to make
  47. something faster is by finding a better way of doing the same thing.
  48. I have attached two files to this message: ByteSwap.c & ByteSwap.h.  In a
  49. nutshell, we do our swapping as follows:
  50.  
  51.  
  52. ByteSwap.h
  53. #define SwapShort(myUnsignedShort)  \
  54.                             ((myUnsignedShort)>>8)|((myUnsignedShort)<<8)
  55. In use:
  56. {
  57.     unsigned short someValue = 0x3210;
  58.     someValue = SwapShort(someValue);
  59. }
  60.  
  61. We quite simply move the hi-byte right, and the lo-byte left, then OR them back
  62. together.
  63.  
  64.  
  65. ByteSwap.c
  66. #include "byteswap.h"
  67.  
  68. unsigned long TransposeLong(unsigned long value)
  69. {
  70.   unsigned long   returnValue;
  71.   ((unsigned char *) &returnValue)[3] = 
  72.                                                     ((unsigned char *)
  73. &value)[0];
  74.   ((unsigned char *) &returnValue)[2] = 
  75.                                                     ((unsigned char *)
  76. &value)[1];
  77.   ((unsigned char *) &returnValue)[1] = 
  78.                                                     ((unsigned char *)
  79. &value)[2];
  80.   ((unsigned char *) &returnValue)[0] = 
  81.                                                     ((unsigned char *) &value)[3];
  82.   return returnValue;
  83. }
  84. David
  85. Most
  86. The Technical Editor Responds
  87. There are quite a few methods available for byte swapping, but which algorithm
  88. is the best depends a great deal on the compiler and processor you are using. 
  89. For instance, the PowerPC (and many other processors) have instructions
  90. specifically for this purpose.  Unfortunately, since the C and C++ languages
  91. have not kept up with current processors (C is basically processor-independent
  92. PDP-11 assembly language), it is our job to trick the compiler into generating
  93. the correct code.
  94. Some compilers provide directives for this purpose.  For instance, if you are
  95. using CodeWarrior on a PowerPC you can just say:
  96.  
  97. inline long SwapLong(long val)
  98. {
  99.     return __XXXXX(val);        //  <<<need intrinsic for load byte-swapped>>>
  100. }
  101. You may notice that I’m using C++ inline functions here instead of C #defines. 
  102. To quote the “Apple Unofficial C++ Style Guide” (develop 2, p. 209): “One of the
  103. most powerful features of the C++ language is the C preprocessor. Don’t use it.”
  104.  Inline functions are not only more readable than preprocessor macros, but,
  105. because they limit side effects, allow the compiler more latitude in optimizing
  106. your code.
  107. Barring that, we need to find something that we can say in C that can get bytes
  108. swapped without generating egregiously bad code.  David’s solution is probably a
  109. good one for shorts because it is a pure mathematical expression, allowing the
  110. compiler to optimize it in any way it chooses.  For longs, his solution is one
  111. of the safest, if you know nothing about the compiler and/or processor you’re
  112. building for.  (I would, however, convert both to inline functions.)
  113. However, if you do know something about your processor, you can do better. In
  114. the case of the PPC, you really want to get your compiler to emit a load
  115. byte-swapped instruction.  On a 680x0, you have a little latitude.  One trick
  116. that comes to mind is that the 680x0 has predecrement and postincrement
  117. addressing modes.  This means that:
  118.  
  119. foo = *p++ and foo = *--p
  120. are fast and (1 instruction)
  121.  
  122. foo = *++p and foo = *p--
  123. are slow (3 instructions).  Therefore we can swap a long on a 680x0 with:
  124. inline long SwapLong(long val)
  125. {
  126.     Byte* p = ((Byte*) val)[4];     // 680x0’s are big-endian
  127.  
  128.                 long val = *--p;
  129.                 val  = (val << 8) | *--p;
  130.                 val  = (val << 8) | *--p;
  131.              return (val << 8) | *--p;
  132. }
  133. The PowerPC has only post-increment instructions, so this will generate lousy
  134. code.  (If someone would like to time a bunch of approaches, I’d be glad to
  135. publish the results.)
  136. I must say that the bottom line is: this is all a bunch of work that would be
  137. completely unnecessary if the C language had kept up with reality.  Here’s my
  138. proposal to the ANSI committee:
  139. Make littleendian and bigendian storage classifiers like const and volatile. 
  140. Then I could just type:
  141.  
  142. typedef struct Foo
  143. {
  144.     littleendian long    bar;
  145.     bigendian short      baz;
  146. } Foo;
  147.  
  148. void blah(Foo* foo)
  149. {
  150.     long  bar = foo->bar;
  151.     short baz = foo->baz;
  152.  
  153.     ...
  154. }
  155. ...and let the compiler deal with it while I spend my time writing code which
  156. does real work.
  157. – sgs
  158.  
  159.  
  160. Fix For Tip Of The Month, January 1996
  161. I’m sending this short note just to point out that, although Greg Poole is right
  162. in writing that a file or directory can be moved by the CatMove function only if
  163. both the source and destination are on the same volume, he seems to forget that
  164. every Macintosh volume, not just the System volume, has a Trash folder.
  165. Thus, if we pass to the FindFolder function the volume reference number of the
  166. file to be deleted instead of the constant kOnSystemDisk, we will be able to
  167. find the directory ID of the local Trash.
  168.  
  169. Line #44 of “FSpTrashFile.c” source file should be changed from:
  170. theErr = FindFolder( kOnSystemDisk, kTrashFolderType, 
  171.                                      kDontCreateFolder, &vRefNum, &dirID );
  172. to:
  173. theErr = FindFolder( (*theFile).vRefNum, kTrashFolderType, 
  174.                                      kDontCreateFolder, &vRefNum, &dirID );
  175. Live Long and Prosper!
  176.  
  177. Luigi Belverato
  178.